home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1759 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.8 KB
  1. From: evanlang@uss.lonestar.org (Evan Langlois)
  2. Subject: Diffs
  3. Date: Sat, 23 Jul 1994 11:41:47 -0500 (CDT)
  4.  
  5. OK, I have finally worked all the bugs out of my file cookie cache
  6. routines.  Well, all the serious ones :-)  There are a few left where
  7. a cache entry is found when it shouldn't have been and sometimes the
  8. system will think a file is still in use when it isn't.  These will
  9. have to be fixed gradually (the entire fcookie cache code is ifdef'd
  10. so you can compile without it).
  11.  
  12. My changes are relative to Mint 1.10 h5 (with some other patches that
  13. didn't make it until h6).  Now h7 is out.  How do I apply the patches
  14. for h7 AND my own??  What diff command will create the proper diffs?
  15. Do I use diff3?  And if so, how?   I've gotten out of sync and I need
  16. help.
  17.  
  18. Tests are real good.  Preliminary tests bring 2 minutes 18 sec.s down
  19. to 1 minute 14 seconds.  And another test that was an unbearable 7
  20. minutes and 6 seconds dropped to only 3 minutes and 4 seconds.  So,
  21. access is down to half the time on average!   
  22.  
  23. Oh, I don't think the hacks that make VDI and AES allocates memory
  24. M_KEEP are useful.  Under normal TOS, wouldn't this memory be attached
  25. to the process and free'd on exit??  I get no memory leaks at all
  26. changing the last of these so that memory allocation from the ROMs is
  27. no longer kept.  I'm not sure if this breaks memory protection, but
  28. before I would lose a small amount of memory when some GEM programs
  29. quit, so perhaps maybe VDI and AES memory SHOULD be free'd on process
  30. exit ??
  31.  
  32. As soon as someone tells how to go about making this diff, I'll post
  33. em and you can start fixing the last of the problems <grin>.  Either
  34. that or I'll make the diffs and then apply them to the new kernel by
  35. hand.  Most of the changes are large blocks and not one-liners, so
  36. I should be able to make the changes.   Should this relative to h8?
  37.  
  38. Thanks!
  39.  
  40. ~.
  41.  
  42.  
  43.